Kiểm thử không thể xác định hoàn toàn được tất cả các lỗi bên trong phần mềm.[2] Thay vào đó, nó so sánh trạng thái và hành vi của sản phẩm với các oracle - các nguyên tắc hay cơ chế để phát hiện vấn đề. Các oracle này có thể bao gồm (nhưng không giới hạn ở) các đặc tả phần mềm, hợp đồng,[3] sản phẩm tương đương, các phiên bản trước của cùng một sản phẩm, phù hợp với mục đích dự kiến nhằm đáp ứng sự kỳ vọng của người dùng, khách hàng, quy định của pháp luật hiện hành và các tiêu chuẩn liên quan khác.

Mục đích chính của kiểm thử là phát hiện ra các lỗi phần mềm để từ đó khắc phục và sửa chữa. Việc kiểm thử không thể khẳng định được rằng các chức năng của sản phẩm đúng trong mọi điều kiện, mà chỉ có thể khẳng định rằng nó không hoạt động đúng trong những điều kiện cụ thể.[4] Phạm vi của kiểm thử phần mềm thường bao gồm việc kiểm tra mã, thực hiện các mã trong môi trường và điều kiện khác nhau, và việc kiểm thử các khía cạnh của mã: nó có làm đúng nhiệm vụ của nó hay không, và nó có làm những gì cần phải làm hay không. Trong môi trường phát triển phần mềm hiện nay, một đội kiểm thử có thể tách biệt với đội phát triển. Các thành viên trong đội kiểm thử giữ các vai trò khác nhau. Các thông tin thu được từ kiểm thử có thể được sử dụng để điều chỉnh quá trình phát triển phần mềm.[5]

Mỗi sản phẩm phần mềm có một đối tượng phục vụ riêng. Ví dụ như đối tượng của phần mềm trò chơi điện tử là hoàn toàn khác với đối tượng của phần mềm ngân hàng. Vì vậy, khi một tổ chức phát triển hoặc đầu tư vào một sản phẩm phần mềm, họ có thể đánh giá liệu các sản phẩm phần mềm có được chấp nhận bởi người dùng cuối, đối tượng phục vụ, người mua, hay những người giữ vai trò quan trọng khác hay không. Và việc kiểm thử phần mềm là một quá trình nỗ lực để đưa ra những đánh giá này.

Khiếm khuyết và thất bại

Không phải tất cả các khiếm khuyết của phần mềm bị gây ra bởi lỗi lập trình mà cội nguồn chung của các khiếm khuyết đó nằm ở những thiếu sót trong yêu cầu; ví dụ, yêu cầu không được xác nhận mà gây ra lỗi là sự sơ suất của các nhà thiết kế của chương trình.[6] Những thiếu sót yêu cầu thường thấy trong những yêu cầu phi chức năng như là khả năng kiểm thử, khả năng mở rộng, bảo trì, tính khả dụng, hiệu suất, và khả năng bảo mật.

Lỗi phần mềm xảy ra thông suốt quá trình như sau: Một lập trình viên làm cho một lỗi (sai lầm), mà kết quả cho ra là một khiếm khuyết (thất bại, sai sót) trong mã nguồn phần mềm. Nếu lỗi này được thực hiện, trong những tình huống nhất định hệ thống sẽ tạo ra kết quả sai, gây ra một sự thất bại.[7] Không phải tất cả các khiếm khuyết nhất thiết sẽ dẫn đến thất bại. Ví dụ, lỗi trong mã chết sẽ không bao giờ dẫn đến thất bại. Lỗi có thể biến thành một sự thất bại khi môi trường thay đổi. Ví dụ về những thay đổi trong môi trường bao gồm các phần mềm đang chạy trên một nền tảng phần cứng máy tính mới, thay đổi trong nguồn dữ liệu, hoặc tương tác với các phần mềm khác nhau. Một khiếm khuyết duy nhất có thể dẫn đến một loạt các dấu hiệu thất bại.

Kết nối đầu vào và điều kiện tiền đề

Một vấn đề rất cơ bản với kiểm thử phần mềm là việc kiểm thử tất cả các kết nối đầu vào và điều kiện tiền đề (trạng thái ban đầu) là không khả thi, ngay cả với một sản phẩm đơn giản.[4][8] Điều này có nghĩa rằng số lượng các khiếm khuyết trong một sản phẩm phần mềm có thể rất lớn và có thể xảy ra thường xuyên nên rất khó để tìm thấy trong quá trình kiểm thử. Quan trọng hơn, những yêu cầu phi chức năng về chất lượng (làm nó như thế nào hơn là làm được gì?) như: tính khả dụng, khả năng mở rộng, hiệu suất, khả năng tương thích, độ tin cậy nếu xét về mặt chủ quan thì nó chưa tạo nên giá trị đủ để mọi người có thể chấp nhận được nó.

Các nhà phát triển phần mềm không thể kiểm thử được tất cả mọi thứ, nhưng họ có thể sử dụng tổ hợp thiết kế kiểm thử để xác định số lượng tối thiểu của các kiểm thử cần thiết để bao quát được những điều họ muốn. Dù là kiểm thử tốc độ hay độ sâu thì họ có thể sử dụng phương pháp này để xây dựng được những cơ cấu khác nhau trong từng trường hợp kiểm thử (test case) cụ thể.[9]

Kinh tế

Một nghiên cứu được tiến hành bởi NIST trong năm 2002 cho biết rằng các lỗi phần mềm gây tổn thất cho nền kinh tế Mỹ 59,5 tỷ đô mỗi năm, hơn một phần ba chi phí này có thể tránh được nếu việc kiểm thử phần mềm được thực hiện tốt hơn.[10]

Người ta thường tin rằng, một kiếm khuyết nếu được tìm ra sớm hơn thì chi phí để sửa chữa nó sẽ rẻ hơn. Bảng dưới đây cho thấy chi phí sửa chữa các khiếm khuyết tùy thuộc vào giai đoạn nó được tìm ra.[11] Ví dụ, một vấn đề được tìm thấy sau khi đã ra bản phần mềm chính thức rồi sẽ có chi phí gấp 10-100 lần khi giải quyết vấn đề từ lúc tiếp nhận yêu cầu. Với sự ra đời của cách thức triển khai thực tiễn liên tục và các dịch vụ dựa trên đám mây, chi phí tái triển khai và bảo trì có thể làm giảm bớt theo thời gian.

Vai trò

Kiểm thử phần mềm được thực hiện bởi nhiều Tester. Cho đến những năm 1980, thuật ngữ "nhân viên kiểm thử phần mềm" đã được sử dụng thường, nhưng sau đó cũng được coi là một nghề riêng biệt. Liên quan đến các giai đoạn và các mục tiêu khác nhau trong kiểm thử phần mềm[12] thì những vai trò khác nhau đã được thiết lập cho các nhà quản lý, trưởng nhóm kiểm thử, nhà phân tích kiểm thử, nhà thiết kế kiểm thử, Tester, nhà phát triển tự động hóa và quản trị viên kiểm thử.